Technical Field
The present disclosure concerns reducing network request response times over a server-signed network connection. More particularly, the present disclosure concerns reducing response times over a server-signed connection that includes unsigning, inline, transparent proxies.
Description of the Related Art
Managing and reducing network request response times is an ongoing challenge in today's increasingly data-rich world. Although many network connections are frequently active, most go idle for at least small periods of time in between communications. Idle connection time is highly valuable because it provides an opportunity to deploy response time reduction mechanisms. Read-ahead operations, for instance, can reduce the amount of data traversing a network connection in certain environments. Client proxies use read-ahead operations to proactively fetch data prior to receiving an actual client request for the data. To do so, a client proxy transmits a mimicked or “read-ahead” client request to an upstream network device (e.g., a server proxy, server, router, transparent bridge, or other network device). Upon receiving a response to the read-ahead request, the client proxy stores the response in memory (e.g., cache memory) for quick retrieval when it subsequently receives an actual client request that matches the read-ahead request. Doing so allows the client proxy to supply the response data to the client on-demand rather than having to transmit the request to a network device (e.g., a server proxy), wait for the device to process the request, and then wait for the response to traverse the network connection.
Although conventional read-ahead operations are beneficial in certain network environments, those in the networking field generally view such operations by unsigning, inline, transparent proxies as useless in environments that feature server-signed responses. In an environment employing a server-signed protocol (e.g., server message block or “SMB” protocols), a server processing a client request must securely sign each of its responses. The server signature assures the client that the response truly originated from the server as opposed to an impersonating device (e.g., in the case of a “man in the middle” attack or the presence of an inline, transparent proxy). The client cannot accept any response that lacks the requisite server signature. Although the problem may be mitigated when the proxies themselves possess copies of the server signing keys (e.g., they can resign the responses directly), transparent proxies often lack access to such keys. As a result, conventional read-ahead operations only work efficiently on signed connections featuring inline, transparent proxies when the speculative read-ahead request is identical to the actual client request received by the client proxy. If the actual client request differs such that the cached read-ahead response is not valid as a response to the actual client request, then the client will not accept the cached response. Because the client proxy cannot construct a valid signature, the signing field appearing in the read-ahead response stored by the client proxy will prevent the client proxy from constructing a valid response from the cached response.
Further compounding the problem, client requests transmitted using server-signed protocols feature a counter field called a message ID (or, interchangeably, a multiplex ID). When the server receives a client request containing a particular message ID, it must not only sign its response, but it must also include a matching message ID. If the message ID provided in the response fails to match the message ID in the client request, the client cannot accept the response. Thus, multiple issues limit the utility of using conventional read-ahead operations in signed connections that feature unsigning, inline proxies (e.g., transparent, inline proxies). As a result, valuable idle connection time is wasted when a connection employs a server-signing protocol and includes unsigning, inline, transparent proxies.
Like read-ahead operations, inline compression operations can also reduce the amount of data that must traverse a network connection. By reducing the size of the data requiring delivery, inline compression promotes faster transfers and lower network traffic. Inline compression on its own, however, fails to remedy the problems associated with using conventional read-ahead operations in signed connections that feature unsigning, inline proxies.
Thus, there is a need for technologies that better harness the benefits of read-ahead operations in server-signing environments despite the presence of unsigning, inline, transparent proxies.